【レポート】 EC2インスタンス ネットワークパフォーマンス最適化 (Optimizing Network Performance for Amazon EC2 Instances) #reinvent #CMP315
はじめに
本記事は AWS re:Invent 2017 のセッション「CMP315 - Optimizing Network Performance for Amazon EC2 Instances」のレポートです。
スピーカー
- Nick Matthews - Partner Solutions Architect, Networking
概要
Many customers are using Amazon EC2 instances to run applications with high performance networking requirements. In this session, we provide an overview of Amazon EC2 network performance features—such as enhanced networking, ENA, and placement groups—and discuss how we are innovating on behalf of our customers to improve networking performance in a scalable and cost-effective manner. We share best practices and performance tips for getting the best networking performance out of your Amazon EC2 instances.
資料
レポート
概要
- パフォーマンスとは（概念）
- OSの微調整
- ネットワークパフォーマンスの種類
- 拡張ネットワーキング
- EC2 の機能
- 構造的なパフォーマンス
- ネットワークの地理的位置
- 負荷分散（ロードバランシング）
パフォーマンスとは
基本的な概念
- 帯域幅
- レイテンシ
- 転送速度（スループット）
- ジッタ
- Jitter = 乱れ、ばらつき
- リアルタイム通信（ボイスなど）で重要
帯域幅は製品（の動作）を遅らせる
- bps = 1回にどれだけのデータを送信できるか
TCPとレイテンシ
- レイテンシが真に問題になるケース:
- クロスリージョンの接続性
- HPCにおけるクラスタ内のインスタンス間通信
- キャッシュ（Elasticatch、memcatchd）
- チューニング
- TCPチューニング
- MTUを大きく設定する
- ネットワークの効率利用
- 物理特性を身近にする
- AWSリージョンの選択 : 数十ミリ秒
- AZ : 数ミリ秒
- プレースメントグループ : 1ミリ秒以下
TCPチューニングの例
- NET401セッションより :
- TCP 受信ウインドウ
- Initial congestion window
- TCP congestion control アルゴリズム
- TCP retransmission timer
その他の性能関連のセッション
- CMP207 - High Performance Computing on AWS
- CMP301 - Deep Dive on Amazon EC2 Instances, Featuring Performance Optimization Best Practices
パケット毎秒 (PPS) と MTU
- MTU = Maximum Transmission Unit
- 全てのパケットは処理にオーバーヘッドを抱えている
- パケットサイズを大きくすると全体のパフォーマンスが向上する
- ジャンボフレーム (9001 MTU)
- ジャンボフレームは1パケット内で使えるデータ量を拡大する
AWS ネットワーク性能
AWS 内ネットワーク
- AWSネットワーキング
- EC2 インスタンスサイズが大きければパフォーマンスも高くなる
- 拡張ネットワーキング
- 1Mppsを超えるパフォーマンス
- インスタンス間通信のレイテンシを削減
- PCIeパススルーによる SR-IOV のサポート
- 一貫して驚くべきパフォーマンス
- Intel ixgbevf と ENA
ENA : Elastic Network Adapter
- 機能としては最大 400Gbps をサポート
- デバイスキューの拡大
- 低レイテンシ、低ジッタ
- 幅広い OS AMIをサポート
- Linux
- AMazon Linux
- RHEL 7.4
- SLES 12
- Ubuntu 14.04, 16.04
- CentOS 7 (1711)
- Linux カーネル 4.9以降
- Windows Server
- 2008 R2
- 2012 R2
- 2016
- FreeBSD 11
- DPDK サポート（16.04より開始）、PMD サポート
- Open Source
- Linux
拡張ネットワークの対レイテンシ性能向上 (RTT)
ネットワーク転送速度
- 全てのリージョン、全ての ENA インスタンスタイプで 25Gbps
Amazon EC2 の性能
- 新しいインスタンスタイプ（c5,i3,p3,r4）は高い性能
- 小さなインスタンスは最大で 10Gbpsまで
- 大きなインスタンスは占有 10 Gbps または 25Gbps
- インスタンスサイズは総ネットワーク容量に影響する
- インスタンスはEBS専用の帯域も持つ
ネットワークとストレージのスループット
拡張ネットワーキングの必要条件
- インスタンスは ixgbevf と ENA の両方をサポートする
- ixgbevf : c3, c4, d2, i2, m4 (m4.16xlarge以外), r3
- ENA : c5, f1, g3, p2, p3, r4, i3, x1, x1e, m4.16xlarge
- AMIは正しいドライババージョンをサポートする
- ixgbevf 2.14.2以降、全ての ENA リリース
- AMI / インスタンスのアトリビュートで有効化
ENA 対応 AMI の確認
- ENA 拡張ネットワーキング
aws ec2 describe-image-attribute --image-id <ami_id> \ --attribute enaSupport
インスタンスでの ENA の有効化
- 拡張ネットワーキングを有効にせずにインスタンスを起動
- ENAカーネルドライバをビルド
- 新しい AMI を構築する、あるいはインスタンスを修正する
# aws ec2 modify-instance-attribute \
--instance-id <instance_id> --ena-support
Or
# aws ec2 register-image --ena-support ...
インスタンスでの ixgbevf の有効化
--attribute sriovNetSupportオプションを指定してdescribe-instance-attributeを確認- レスポンスに
"SriovNetSupport": { "Value": "simple" }とあればサポートしている
- レスポンスに
拡張ネットワーキングの確認
- PV-Xen
ethtool -k eth0...driver.vif
- 拡張ネットワーキング
ethtool -i eth0...driver.ixgbevf- c3, c4, d2, i2, r3, m4 (m4.16XL以外)
- ENA
ethtool -i eth0...driver.ena- c5, f1, g3, p2, p3, r4, i3, x1, x1e, m4.16xlarge
DPDK と AWS
- Intel Data Plane Development Kit (DPDK)
- 高速パケット処理のための Cライブラリとドライバ
- 拡張ネットワーキングをサポート
- ixgbevf と ENA
- レイテンシの削減
事例 : Supercell - Crash of Clans
- インスタンス間で数千の TCP コネクション
- 「クラッシュ・オブ・クラン」を EC2 Classic から VPC へマイグレートした
- 全て拡張ネットワークを ON にしたインスタンス
マイグレートした結果
- EC2クラシックでは数百のインスタンスが数千のTCPコネクションを選るまでに 30 分 初期化にかかった
- 拡張ネットワーキングにした 1 分以下になった
- 効果
- TCPの信頼性
- モニタリング
- データベースコネクション
- メッセージキューのサイズが劇的に減少
- ネットワークメンテナンスとアップデートのためのダウンタイム
- 1時間 -> 20分
アーキテクチャ
よくある風景
- 送信元・送信先
- プレースメントグループ内
- VPNコネクション
- AWS Direct Connect
- ELB使用
- AWSサービスへのアクセス（S3など）
VPCのネットワーク性能 - 帯域の限界
- VPCに由来する制限はない
- AZまたはサブネットに由来する制限はない
- IGWに由来する制限はない
- NGWは10Gbpsに制限
- 水平に拡張して 10Gbps を超える
VPCピアリングの性能 - 帯域の限界
- VPCピアリングに由来する制限はない
帯域の限界
- インスタンス間
- 25Gbps (VPC または VPCピアリング)
- Amazon S3との間
- 25Gbps (VPCエンドポイント・パブリックIP / 同リージョン内)
VPGの性能 - 帯域の限界
- VPNトンネル毎に1.25Gbpsまで集約
- AWS DXには物理的な制約しかない
- インスタンスからのアウトバウンドトラフィックは 5Gbpsで制限
NLBの性能
- NLB
- L4ロードバランサ
- TCP
- 高性能
- AZローカル
- AZ毎に 1IP
- 帯域の限界
- 起動時に数Gbpsの容量
- スケールアウト
- 参考
- NET304 - Deep Dive into the New Network Load Balancer
- 【レポート】新しいNetwork Load Balancer #NET304 #ELB #reInvent ｜ Developers.IO
パフォーマンス試験
- パフォーマンスには多くの要素がある
- 通信経路、種類、サイズ
- インスタンスファミリ、タイプ
- アプリケーションの特性
- パケットサイズ
- プロトコル
- CPU / メモリ / ディスク使用量
- AWS からの推奨 :
- 自分で試せ (test it yourself)
どうやって？
- あなたのアプリケーションと環境による
- 負荷テスト
- トランザクションテスト
- "Race track numbers"（？）
- ベンチマークテスト
- シナリオテスト : VPC内、インターネットとの通信、VPN
- 帯域、レイテンシ、ジッタ、スループット、pps
Tips
- 複数のフローを投げる
iperf -c 192.168.1.1 -P 10
- 可能なら UDP
iperf -c 192.168.1.1 -u -p <port number>
- テストツール
- https://github.com/newsapps/beeswithmachineguns
- ネットワークのベンチマークテスト
まとめ
- レイテンシとTCPのダイナミクスを理解せよ
- レイテンシを削減
- AWS が何を提供しているか理解せよ
- 拡張ネットワーキング、ジャンボフレーム(MTU)、インスタンスファミリ
- 正しいアーキテクチャを使え
- 限度を知り、負荷を散らす
- テストしろ (Test it Out)
おまけ (New!)
所感
とにかく「自分でテストを」と強調していたところが印象的でした。自分でもパフォーマンスチューニングに王道はない（そんなものがあれば最初からそう設定されているので）という感覚でしたので、その裏付けがとれた気がします。
